Download the artifacts for this pull request:

Would it be worth adding a property to distinguish between a playlist that is created with this option? This PR currently will populate the playlist-path property with whatever you first opened mpv with which might be unexpected (e.g. local single file instead of a directory, playlist file, etc.)

Would it be worth adding a property to distinguish between a playlist that is created with this option? This PR currently will populate the playlist-path property with whatever you first opened mpv with which might be unexpected (e.g. local single file instead of a directory, playlist file, etc.)

I agree, but in the same time I find it quite telling that the playlist was created with a original file being the local file.

added filtering and docs

--autocreate-playlist breaks external files like subtitles.

While I have never wanted to give a file and have mpv generate a list of files in same directory, there is one thing I want that I think is missing:
I want to give mpv a directory and request mpv to play all audio files in that directory and sub directories.
While I today can give a directory for mpv to play all files in, I cannot request it to only play audio files.
Unless I am mistaken that is not solved here but ought to be easy to add to the code.

Unless I am mistaken that is not solved here but ought to be easy to add to the code.

I don't want to mix this changes, this is completely different. For example it would likely be a different option, because you want different filtering for autocreated playlist and different for directory opened directly.

I want to give mpv a directory and request mpv to play all audio files in that directory and sub directories.

Added --directory-playlist-exts, since there were no other complains to work on.

Maybe combine normal directory playlists and autocreated?
Something like:

--playlist-video-exts=<ext-list>
--playlist-audio-exts=<ext-list>
--playlist-image-exts=<ext-list>

--autocreate-playlist=<no|any|filter|same>
--playlist-filter-exts=<no|video|audio|image>

So you can define the exts for audio/video/images if default is not wanted.
If autocreate-playlist is used it will be created from director of given file. Setting filter requests the defined filter exts to be used.
playlist-filter-exts is used for directory and autocreate. no means no filter is used, or you specify which ext set you want to filter on.
Maybe this option could allow more then one ext set to be specified so you could request for audio and video but no images.

This way the options get shorter names and works both for autocreated and for directory created.

@DanOscarsson: updated.

--directory-filter-type=foo --directory-mode=lazy doesn't add subdirectories. Also these options could just be called --directory-video-exts and so on.

--directory-filter-type=foo --directory-mode=lazy doesn't add subdirectories. Also these options could just be called --directory-video-exts and so on.

Thanks guido, should be better now.

This PR doesn't have feature parity with autoload.lua yet, notably ignore patterns. Until this PR has 100% feature parity I don't think autoload.lua should be removed.

I will merge this later. Honestly I don't have energy to look at this again, let users test it and fix remaining issues as they arrive.

it breaks RESUMING PLAYBACK

autocreate-playlist=same
save-position-on-quit=yes
watch-later-options=start,speed,volume

values are saved correctly, but the start value is ineffective, always resume playback from the beginning.

There is also a problem that when opening a single file it creates the playlist normally with --autocreate-playlist=same, but when opening another file in another path it doesn't automatically create the playlist again, which doesn't match the expected behavior.

which doesn't match the expected behavior.

Says who? If there is a playlist present already, there will NOT be another one created or otherwise no new items will be appended based on autocreate logic.

values are saved correctly, but the start value is ineffective, always resume playback from the beginning.

https://github.com/mpv-player/mpv/blob/master/player/loadfile.c#L1682-L1684

We delete the watch_later config if we have a playlist

which doesn't match the expected behavior.

Says who?

This is not quite the same behavior as the autoload.lua script, which creates a new playlist based on the directory of another path when opening a file in another path with loadfile path command.

If there is a playlist present already, there will NOT be another one created or otherwise no new items will be appended based on autocreate logic.

The current behavior does not create a new playlist based on the new path with loadfile path command, it empties the current playlist and loads only one file, which is not wanted.

it empties the current playlist and loads only one file

Should be fixed by #14661. Test the build from the PR.

it empties the current playlist and loads only one file

Should be fixed by #14661. Test the build from the PR.

Yes, it fixes.

is there an option to automatically add new videos to the playlist if there are new videos in the folder?

is there an option to automatically add new videos to the playlist if there are new videos in the folder?

No.

It's still better to use autoload.lua to detect newly added videos from downloads.

It's still better to use autoload.lua to detect newly added videos from downloads.

I don't think autoload.lua watches directory for new files. It may load them when the next file is loaded, but it is just an side-effect of how the script work.

It may load them when the next file is loaded, but it is just an side-effect of how the script work.

Will there be a feature similar to load them when the next file is loaded?